fix(evo-flow): reuse primary app context in action-node activities (EVO-1829)#75
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Journey/campaign action nodes (Add Label, Remove Label, Update Custom Attribute, Transfer Journey) + campaign-execution activities run outside the Nest DI container. Each one bootstrapped a full second
AppModuleviaNestFactory.createApplicationContext(AppModule.forRoot())just to resolve a DI service. In single-mode that boots a redundant Temporal worker + Kafka consumers + ScheduleModule jobs in the same process — they collide and the app silently freezes the first time an action node runs per boot (HTTP server dies, session stuckactiveon the node). Same family as EVO-1737, different path.Fix (chosen via a design evaluation of 3 approaches): stash the primary application context at boot in a tiny module-level holder, and resolve services from it via
getAppContext(). No secondAppModuleis ever booted. The primary context already provides every service these activities need and is guaranteed to exist before any activity dispatch.Changes
src/shared/app-context.holder.ts(new):setAppContext/getAppContext(type-only import; fail-fast throw, never a silent hang).src/main.ts:setAppContext(app)right afterNestFactory.create()(before init/worker creation in all RUN_MODEs).campaign-execution.activities.ts: resolve DI viagetAppContext(); drop the per-nodecreateApplicationContext(AppModule.forRoot())bootstrap + dead imports.no-app-bootstrap.guard.spec.ts(new): regression guard forbidding the bootstrap pattern underactivities/.journey-tracking.activities.tsnew KafkaService()(deliberate producer-only force-init).Validation
evo-flow: npm run build→ cleanevo-flow: npx jest(guard + campaign + add/remove-label + update-custom-attribute + conditional + split) → 64/64evo-flow: npx prettier --check→ new files + main + campaign spec clean (the 4 node files + campaign activity had pre-existing prettier drift on develop, intentionally not reformatted to keep the diff focused)journey-trigger → add-label (started → completed) → exit, sessioncompleted, label applied, app stays up, and no second AppModule bootstrap appears in the logs.Acceptance Criteria
Changed Files
src/shared/app-context.holder.ts(new)src/main.tssrc/modules/temporal/activities/nodes/{add-label,remove-label,update-custom-attribute,transfer-journey}.node.tssrc/modules/temporal/activities/campaign-execution.activities.tssrc/modules/temporal/activities/campaign-execution.activities.spec.tssrc/modules/temporal/activities/no-app-bootstrap.guard.spec.ts(new)Linked Issue
🤖 Generated with Claude Code
Summary by Sourcery
Reuse the primary Nest application context for Temporal campaign and action-node activities instead of bootstrapping a second AppModule, preventing single-mode freezes and redundant workers.
Bug Fixes:
Enhancements:
Tests: